Developers commonly spend a significant amount of time debugging programs. Developers often apply the scientific method when debugging a program: they observe a program's behavior on different inputs, first to reproduce a bug, then to localize the bug in the program's source. Reproducing, localizing, then fixing a bug typically involve forming and validating hypotheses about a root cause of the bug. The root cause of the bug is a first point at which a state of the program diverges from an intended state. To validate a hypothesis, a developer often halts program execution and examines the state of the program. Especially early in debugging, when the developer's quarry is still elusive, execution is commonly halted too soon or too late to validate a hypothesis. Overshooting (e.g., late halting of the execution of the program) can be expensive because returning to an earlier point in an execution of a program commonly involves restarting and re-running the program.
Integrated development environments (IDEs) commonly provide various tools for developing a program. Many conventional IDEs include a source code editor, build automation tools, and a debugger. The debugger can be used to halt program execution and examine the state of the program (e.g., via a graphical user interface (GUI) provided by the IDE). However, tool support for debugging has remained relatively unchanged for many years. Accordingly, the cost of restarting and re-running the program when a breakpoint is placed too late in the execution of the program remains.